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1. 


Introduction 


The  Core  Plan  Representation  (CPR)  is  an  effort  to  develop  a  plan  representation  which  supports 
the  representation  needs  of  many  different  planning  systems.  The  goal  of  this  effort  is  to  leverage  common 
functionality  and  facilitate  the  reuse  and  sharing  of  information  between  a  variety  of  planning  and  control 
systems.  The  CPR  attempts  to  embody  a  standard  which  is  general  enough  to  cover  a  spectrum  of  domains 
from  planning  and  process  management  to  workflow  and  activity  models.  In  addition,  the  proposed 
representation  will  be  powerful  enough  to  support  complex,  hierarchical  plan  structures.  The  prime 
motivation  for  the  CPR  effort  is  to  address  plan  interchange  requirements  of  several  military  planning 
systems,  but  this  proposal  attempts  to  go  beyond  military  planning  and  present  a  more  general  plan 
representation. 

This  document  is  issued  as  a  request  for  comments  on  the  initial  proposal.  Feedback  from  the 
planning  community  is  encouraged  in  order  to  help  refine  this  design  and  broaden  its  acceptance. 

In  order  to  gain  a  full  appreciation  of  the  design,  it  is  important  to  understand  the  design  process  of 
the  CPR.  Section  2  of  this  document  provides  information  about  history,  processes,  and  plans  for  the  CPR. 
It  also  includes  reference  to  some  of  the  research  and  development  efforts  which  contributed  to  the  current 
design.  Section  3  provides  an  overview  and  then  explains  the  design,  incrementally  adding  pieces  of  plan 
information.  A  detailed  description  of  the  complete  design  is  captured  in  Section  4,  including  class  designs 
and  descriptions.  Section  5  provides  a  summary  of  conclusions.. 

Comments,  questions,  or  pointers  to  additional  relevant  information  would  be  greatly  appreciated. 
All  responses  should  be  directed  to  Adam  Pease  at  apease@teknowledge.com. 

2.  Background 

The  design  of  the  CPR  was  derived  from  years  of  research  and  experience.  This  design  attempts  to 
unify  the  major  concepts  and  advancements  in  plan  and  process  representation  into  one  comprehensive 
model.  This  section  first  provides  some  motivation  for  the  CPR  effort  Next  a  significant  desip 
consideration  is  explained.  References  are  then  given  for  research  efforts  which  had  particular  influence  in 
the  desip  process.  Finally  a  notional  schedule  and  process  of  the  next  stages  of  the  CPR  desip  are  given. 

2. 1.  Motivation 

There  are  two  significant  payoffs  to  the  CPR  effort  The  first  is  that  creation  of  a  base  plan 
representation  will  facilitate  information  interchange  among  different  planning  systems.  Imagine  a  generic 
military  planning  situation.  A  crisis  develops  and  a  joint  task  force  is  formed.  The  leadership  and  staff  use 
a  planning  application  to  develop  guidance  for  their  subordinate  commands.  This  pidance  includes 
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background  on  the  situation,  objectives  which  must  be  met  to  contain  the  crisis,  constraints  on  the  actions  of 
the  task  force  and  high  level  specification  of  the  schedule  of  operation.  This  information  is  passed  to 
individual  commands  which  have  specific  requirements  and  methods  of  planning.  A  standard  plan 
framework  enables  improved  information  transfer  to  these  specialized  planning  applications.  Continuing  to 
follow  this  generic  and  hypothetical  example,  the  commander  of  the  air  component  of  the  task  force  and  his 
staff  will  use  their  superiors*  objectives  to  develop  more  detailed  objectives,  lists  of  targets  which  support 
those  objectives,  and  then  repeatedly  create  a  schedule  of  aircraft  sorties  to  destroy  those  targets.  Pilots 
flying  those  sorties  could  benefit  from  performing  simulated  runs.  A  core  plan  representation  enables 
information  from  the  plan  to  be  transferred  to  simulation  entities  possibly  allowing  a  single  pilot  to  fly  along 
side  computer  generated  forces  simulating  the  other  pilots  in  his  flight  While  information  transfers  of  this 
sort  will  rarely  be  complete,  and  will  often  require  further  augmentation  and  elaboration  for  the  new 
application,  the  CPR  will  reduce  the  amount  of  manual  rekeying  and  reformulation  of  existing  data. 

The  second  payoff  is  in  the  creation  of  common  services  based  on  the  CPR.  There  are  two  broad 
areas  of  services  with  immediate  utility.  The  first  area  is  visualization.  Manufacturing,  business  planning 
and  construction  management  all  share  several  basic  forms  of  visualizing  plan  information.  The  CPR 
enables  creation  of  these  common  views  which  will  dramatically  reduce  implementation  time  for  specific 
systems.  Well  designed  common  viewers  can  then  be  specialized  for  particular  planning  applications 
instead  of  written  from  scratch.  The  second  area  is  scheduling.  Many  important  advances  have  occurred  in 
the  operations  research  and  artificial  intelligence  communities  which  allow  software  systems  to  provide 
significant  aid  in  complex  scheduling  problems.  A  complete  scheduling  system  can  rarely  be  build  on 
generic  techniques  alone,  but  the  CPR  enables  the  creation  of  generic  scheduling  tools  which  eliminate  the 
need  to  build  these  tools  from  scratch  each  time  a  new  scheduling  domain  is  targeted. 

2.2.  A  Design  Objective 

The  CPR  attempts  to  model  the  “basic  lever  [Rosch,  1976]  of  plan  representation  for  the  given 
domain  of  planning  needs.  The  basic  psychological  level  is  a  simple  yet  elegant  concept  In  an  ontology  of 
several  levels  describing  a  given  domain,  there  is  one  level  at  which  humans  associate  the  largest  amount  of 
information.  For  example. 


SUPERORDINATE 

ANIMAL 

FURNITURE 

BASIC 

DOG 

CHAIR 

SUBORDINATE 

RETRIEVER 

ROCKER 

Table  1  :  Example  from  [Rosch,  1976] 


There  are  several  attributes  of  the  basic  level.  One  is  that  this  is  the  level  at  which  terms  are  used 
in  neutral  contexts.  For  example  [again  after  Rosch]  There  is  a  dog  on  the  porch  as  opposed  to  There* s  a 
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mammal  on  the  porch  or  There’s  a  wire-haired  terrier  on  the  porch.  The  latter  two  sentences  are  unusual 
and  require  further  explanation. 

For  plan  information,  simply  specifying  objects  Entity  and  Relationship  is  not  enough.  Nor  would 
defining  Plan  as  an  object  without  attributes  be  sufficient  On  the  other  hand,  specifying  the  Plan  as  having 
weatherForcecast  attribute,  or  defining  a  NonshareableResourceConstraint  would  be  too  specific.  Few 

plans  require  this  sort  of  information.  The  CPR  specifies  plan  information  at  the  lowest  level  common  to 
all  planning  systems  of  interest 

It  should  be  noted  that  the  basic  level  is  specific  to  the  domain  being  covered.  If  the  context  of 
interest  is  air  campaign  planning  then  a  weather  forecast  object  is  useful  and  the  CPR  must  be  specialized 
for  that  context  The  CPR  may  be  specialized  to  cover  more  restricted  domains  in  greater  detail.  The  basic 
level  of  plan  information  for  air  campaign  planning  will  container  a  much  richer  set  of  information  than  is 
common  to  planning  in  general. 


2.3.  Prior  research 

Planning  is  a  fundamental  component  of  intelligent  behavior.  The  discipline  of  planning  has  been 
studied  for  generations  in  an  attempt  to  produce  more  effective  plans.  Modem  developments  and 
techniques  from  the  fields  of  artificial  intelligence,  operations  research,  management,  decision  theory  and 
philosophy  have  all  been  applied  to  planning  problems. 

Planning  may  also  be  seen  to  include  that  which  AI  researchers  have  separately  termed  scheduling. 
While  the  CPR  is  targeted  to  address  the  representation  needs  of  both  planning  and  scheduling,  the  two 
areas  are  given  the  following  definitions  in  AI 

Planning  -  Specifying  a  set  of  actions  in  order  to  meet  a  set  of  goals  or 
objectives 

Scheduling  -  Resolving  the  dependencies  among  actions  and  resources 
in  a  plan  to  specify  amounts  of  resources  used  over  time  and  times  at 
which  actions  will  take  place. 

Planning  is  a  significant  area  of  research  within  artificial  intelligence.  A  review  of  this  broad  field 
is  outside  the  scope  of  this  document.  The  interested  reader  is  referred  to  [Tate  et  al,  1990]  and  [Allen  et  al, 

1990].  Scheduling  has  a  significant  body  of  literature  as  well.  For  this,  the  reader  is  referred  to  [Zweben 
and  Fox,  1994]. 

Two  efforts  in  particular  have  influenced  the  CPR.  KRSL-Plans  bears  many  similarities  to  CPR. 

In  fact,  some  of  the  same  people  working  on  KRSL-Plans  have  contributed  significantly  to  the  CPR  design. 
The  goals  of  the  two  efforts  are  slightly  different  however.  While  KRSL-Plans  is  working  on  developing  an 
ontology  of  plans  and  activities,  CPR  is  striving  for  an  object  oriented  software  design  developed  with  a 
strong  ontological  awareness.  It  should  be  notes  that  KRSL-Plans  like  CPR  is  also  an  ongoing  effort 
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although  it  began  much  earlier.  I-N-OVA  [Tate,  1996]  is  another  ongoing  effort  which  bears  some 
similarity  to  CPR  due  to  the  significant  contribution  of  Austin  Tate  to  the  CPR  effort 

2A.  Process  and  Schedule 

The  CPR  design  effort  was  begun  in  May  of  1996.  Background  was  collected  and  a  “strawman” 
design  was  created.  This  information  served  as  inputs  to  a  Core  Plan  Representation  meeting  held  July  15- 
16,  1996.  Members  of  the  meeting  included  ARPA  researchers  working  on  planning  and  ontology  issues. 
Many  had  also  created  major  planning  systems.  Also  in  attendance  were  software  developers  for  the  JTF- 
ATD  [Hayes-Roth  andErman,  1994]  [Hayes-Roth,  1995]  [Carrico,  forthcoming]  and  Air  Campaign 
Planning  Tool  who  are  creating  planning  systems  as  part  of  those  efforts.  This  meeting  yielded  progress  on 
many  ontological  issues  related  to  the  CPR  and  on  improvements  to  the  design.  Design  discussions  with 
members  of  this  group  are  ongoing.  A  second  group  meeting  was  held  on  August  6*  with  ARPI  researchers 
some  of  whom  were  present  at  the  July  meeting.  This  second  meeting  yielded  additional  progress 
principally  on  ontological  issues  but  also  on  the  design. 

This  paper  will  be  presented  at  the  ARPI  quarterly  meeting  on  September  24th. 

The  short  term  goal  of  the  CPR  effort  is  to  develop  an  initial  design  which  can  be  implemented  and 
tested  during  the  1996  fiscal  year.  The  long  term  goal  is  to  obtain  wide  scale  acceptance  and  use  of  the 
CPR,  and  seek  sponsorship  to  make  it  an  industry  wide  commercial  standard.  A  tentative  schedule  of  future 
activities  can  be  found  in  Table  2.  Though  the  dates  are  subject  to  change,  the  milestones  should  provide 
insight  into  the  time  frame  and  process  being  pursued.  The  general  process  is  to  seek  design  feedback 
during  an  initial  review  period,  then  freeze  the  design  for  a  period  of  time,  during  which  the  design  will  be 
implemented  and  tested  in  one  or  more  real  application  domains.  As  the  design  stabilizes,  the  process  will 
alter  focus  from  design  to  implementation  evaluation.  This  test  implementation  is  likely  to  involve  the  JTF 
ATD  and  JFACC  programs,  two  premier  military  planning  applications.  Additional  non-military 
applications  may  also  be  considered.  Based  on  the  feedback  from  the  implementation  test,  additional 
changes  and  expansion  of  the  design  will  be  considered.  After  the  revised  design  is  worked  through,  there 
will  be  another  general  request  for  comment  as  a  precursor  to  application  for  standards  acceptance.  After 
that  proposal  review  period,  adoption  as  an  official  DoD  standard  will  be  pursued. 


4 


Sept  96 

Initial  draft  release  of  the  CPR  design  for  general  review  and  comment 

Dec  96 

Final  draft  release  of  the  CPR  design  for  general  review  and  comment 

Mar  97 

Initial  experimental  implementation  of  the  CPR  design 

July  97 

Official  standards  proposal  release,  final  request  for  comments 

Sept  97 

Target  standards  acceptance  date 

Table  2 :  CPR  Milestones 


Though  the  timetable  is  extremely  short,  the  history  of  design  and  development  efforts  in  which  the 
CPR  is  rooted  provides  a  sound  foundation.  The  near  term  application  of  the  design  in  an  ongoing 
implementation  effort  should  identify  any  relevant  application  issues.  Finally,  the  ongoing  support  and 
guidance  from  the  combined  knowledge  and  experience  of  the  members  of  ARPI  should  provide  added 
assurance  of  timely  progress. 


3.  Building  the  CPR 

To  develop  an  appreciation  for  the  proposed  CPR  design,  some  of  the  component  objects  will  first 
be  presented.  The  plan  representation  will  constructed  piecemeal  in  order  to  capture  the  design 
motivations,  considerations,  and  open  design  issues.  Finally,  all  the  components  will  be  brought  together  to 
form  the  complete  core  plan  representation.  Readers  who  are  only  interested  in  the  finished  design  may 
skip  to  Section  4. 


3.1.  Foundation  Concepts 

The  first  step  is  to  show  the  minimal  concepts  necessary  to  represent  any  plan.  This  draws  on  the 
work  KRSL,  the  POCG,  and  O-Plan  [Tate,  1994].  The  initial  concepts  are  Action,  Actor,  Objective,  and 
Resource.  An  Action  is  performed  by  an  Actor.  The  motivation  behind  performing  the  Activity  is  to 
accomplish  some  Objective.  In  performing  the  Action,  the  Actor  may  utilize  a  Resource.  An  Actor  in  one 
Activity  could  be  a  Resource  in  another. 

Next,  input  from  the  workflow  and  manufacturing  communities  suggests  that  plans  must  be 
situated  in  time.  TimePoint  object  is  therefore  added  to  the  our  minimal  set.  The  TimePoint  represents 
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some  association  of  the  Action  with  time.  In  considering  the  temporal  reference  of  the  Activity,  it  is  only 
natural  to  then  consider  the  relevance  of  the  spatial  references.  A  SpatialPoint  is  added  to  the  minimal  set 
As  with  TimePoint,  SpatialPoint  has  the  capability  to  represent  an  exact  location,  or  a  vague  area.  It  is 
capable  of  grounding  the  objects  both  in  absolute  and  relative  terms. 

In  considering  the  representation  of  relative  SpatialPoint,  as  well  as  the  association  of  Resources 
with  the  plan,  it  appears  that  relation  needs  to  be  added  our  minimal  set  Relation  is  an  association  between 
elements  of  this  set  including  self  association.  Further,  relations  are  valid  between  most  sets  of  objects. 

The  minimal  set  is  shown  in  figure  3-1.  This  is  the  set  of  core  conceptual  pieces  from  which  CPR 
representation  will  be  constructed. 


Figure  3-1 :  Basic  Concepts 

It  should  be  emphasized  that  the  idea  is  not  necessarily  to  instantiate  the  objects  of  the  core,  but 
rather  use  them  to  better  understand  the  essence  of  a  plan.  If,  in  designing  the  representation  of  the  plan,  it 
is  beneficial  to  use  these  notional  objects  as  parents  in  the  object  trees,  then  all  the  better. 

At  this  point,  many  other  planning  components  could  be  considered,  but  most  can  be  successfully 
mapped  into  one  of  the  existing  core  elements,  or  a  combination  of  the  core  elements.  As  building  blocks,  it 
is  acceptable  that  some  plan  element  mappings  are  not  a  one-to-one  mapping  to  elements  in  the  core.  The 
critical  issue  at  this  point  is  that  a  mapping  exists  for  all  important  elements  of  a  plan. 

With  the  core  in  place,  the  job  of  constructing  the  CPR  can  begin. 

3.2.  From  Concepts  to  Design 

It  is  now  time  to  create  the  basic  structure  of  the  plan  from  the  building  blocks  given  above.  No 
attributes  and  methods  are  considered  yet.  A  Plan  consists  of  one  or  more  Actions  performed  in  pursuit  of 
some  Objective.  As  noted  above.  Actors  may  use  Resources  in  the  performance  an  Action.  Under  closer 
scrutiny,  it  appears  that  Actor  and  Resource  are  not  directly  elements  of  the  Plan,  but  rather  of  the  Activity 
itself.  The  design  now  appears  as  in  Figure  3-2. 
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A  Relation  may  be  contained  in  any  of  the  above  objects 

7 - 

Relation 


Figure  3-2  :  Initial  Framework 

It  is  clear  that  from  this  basic  framework  that  a  host  of  other  required  elements  could  be  identified 
and  added.  Because  the  CPR  was  meant  to  be  a  general  purpose,  flexible  representation,  an  extremely 
complex  or  constraining  design  is  inappropriate.  To  that  end,  elements  are  carefully  considered  for  both 
relevance  and  generality  before  being  added.  The  next  step  is  to  review  the  core  and  identify  where  the 
remaining  basic  concepts  reside. 

TimePoints  are  associated  with  the  Activity,  and  help  ground  the  actions  to  be  performed.  Though 
a  number  of  TimePoints  may  provide  information  about  an  Activity,  every  Activity  has  at  least  a  beginning 
and  end,  though  either  may  be  infinite  or  periodic.  While  SpatialPoint  is  information  which  will  often  be 
present  in  a  particular  plan  representation,  it  is  not  present  in  the  CPR.  The  CPR  represents  a  minimal  set  of 
information  common  to  all  plans.  Since  spatial  information  is  not  present  in  many  plans,  this  information 
was  dropped  from  the  CPR  and  will  be  left  for  specializations  of  the  CPR  to  instantiate. 

Due  to  aggregate  nature  of  Plans,  it  is  appropriate  to  allow  a  Plan  to  be  associated  with  another 
Plan,  where  one  would  represent  the  parent  plan  and  the  other  a  sub-plan.  A  similar  argument  may  be  made 
for  both  Objectives  and  Actions,  representing  sub-objectives  and  sub-actions  respectively.  During 
execution  of  the  Plan,  Objectives  are  reviewed  in  order  to  gauge  the  effectiveness  of  the  Plan  and  identify 
when  the  Plan  is  complete.  This  review  is  performed  against  a  set  of  evaluation  criteria  relevant  to  the 
Objective.  The  entity  EvaluationCriterion  was  added  to  Objective  address  this  need. 
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Constraints  and  Uncertainty  are  other  elements  essential  to  planning.  Relations  are  in  fact 
Constraints  on  a  pair  of  objects.  Constraints  capture  conditions  placed  on  Activities  or  Objects.  • 
Uncertainty  captures  the  degree  of  confidence  in  information.  Constraints  and  Uncertainty  have  no  single 
place  in  the  CPR  where  they  would  be  most  appropriate.  As  such,  they  are  left  as  objects  which  can  be 
contained  in  any  object  of  the  plan. 


Constraint  and  Uncertainty  may  be  contained  in  any  of  the  above  objects 

7 - 

Constraint 


Figure  3-3  :  The  Revised  CPR  Framework 

The  framework  is  now  complete  although  some  additions  and  specifics  remain.  This  framework  is 
shown  in  Figure  3-3. 

A  set  of  design  issues  relevant  to  this  framework  have  been  collected,  and  are  listed  in  section  4.1 

below. 


Uncertainty 


3.3.  Completing  the  Design 

Now  a  final  pass  can  be  performed,  bringing  together  the  last  remaining  pieces  and  adding  an 
initial  set  of  attributes  and  methods.  This  section  attempt  to  step  through  that  progression.  Attributes  which 
are  plural  may  be  understood  as  containing  a  list  of  objects. 

First,  Plan  needs  to  be  completed.  It  already  contained  subPlans,  Actions,  and  Objectives.  It 
needs  a  name,  currently  of  type  String.  Additionally,  it  must  have  a  set  of  metadata  describing  the  merits  of 
one  plan  relative  to  others.  This  is  contained  in  the  attribute  evaluation.  The  class  Annotation  is  created  to 
maintain  general  Plan  metadata.  It  is  also  valuable  to  allow  metadata  about  the  status  of  plan  creation.  For 
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this  purpose,  the  issues  attribute  is  added.  Finally,  alternative  plans,  if  available,  should  be  accessible  from 
the  current  plan.  To  support  this,  the  attribute  alternative  is  defined  as  a  list  of  Strings. 

Action  may  now  be  elaborated.  Action  requires  a  name,  similar  to  Plan.  We  have  already 
identified  subActions,  actors,  resources,  and  begin  and  end  TimePoints.  PlanObjects  are  defined  to 
represent  entities  referred  to  in  an  Action  which  are  not  the  Actor  or  a  Resource.  For  example,  the  recipient 
of  a  mail  message  would  be  recorded  as  an  instance  of  PlanObject. 

It  is  clear  that  most  plan  objects  require  a  name.  This  attribute  is  added  to  Plan,  Action,  Actor, 
Resource,  Constraint,  and  Annotation.  Many  of  the  other  objects,  like  Objective,  Imprecision,  and 
Uncertainty,  have  types  or  names  as  well,  therefore  a  name  field  is  added  to  each,  currently  of  type  String. 

Future  iterations  of  the  CPR  may  attempt  to  enumerate  the  allowable  types,  but  this  is  left  unspecified  at  this 
time. 

Actors  may  have  objectives  of  their  own  and  so  a  reference  to  the  plan  objectives  is  added  and 
called  objectives.  Since  the  Actor  may  not  be  a  single  person,  but  represent  an  aggregate  of  some  kind,  the 
attribute  subActors  was  added. 

Objective  contains  type,  subObjectives,  and  evaluationCriteria.  It  requires  some  additional  work. 
To  Objective,  value  is  added  to  hold  the  actual  objective  element,  represented  as  a  String.  Objective  also 
references  the  list  of  Actions  in  the  Plan  which  are  meant  to  satisfy  it 

Constraint  currently  holds  only  name.  In  order  to  complete  Constraint,  additional  fields  are  added 
to  hold  the  terms  of  the  constraint  expression,  any  associated  subConstraints,  and  the  constraint’s 
levelOfHardness.  These  are  represented  as  attributes  of  type  String,  Constraint,  and  Integer  respectively. 
Level  of  hardness  represents  a  relative  priority  for  the  various  constraints  in  a  plan. 

Annotations  consist  of  a  String  name  and  the  body  of  the  annotation.  In  addition,  the  annotations 
could  be  constructed  hierarchically  to  form  linked  documentation,  and  thus  a  list  of  subAnnotations  is 
required. 

Uncertainty  and  Imprecision  are  both  required  but  different  plans  may  have  very  different 
requirements  for  handling  them.  There  is  an  understanding  that  each  would  have  a  type,  a  measure,  and  a 
source,  but  the  latter  two  do  not  have  a  clear,  common  representation.  As  such,  they  are  currently  left 
undefined. 

Assumptions  are  currently  represented  as  the  assumption  data,  and  triggers  which  identify  when 
that  assumption  data  becomes  invalid  and  what  to  do  when  that  condition  occurs.  The  trigger  is  therefore  a 
condition-action  pair  but  again,  a  common  representation  is  most  likely  not  possible  and  it  will  remain  to 
specializations  of  the  CPR  to  instantiate  their  specific  requirements. 
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Finally,  some  additional  components  were  identified,  but  require  additional  consideration.  The 
first  is  Fact,  which  is  a  basic  data  component  having  a  String  name  and  a  list  of  terms.  The  second  is  a 
Frame,  which  consists  of  a  set  of  attribute-value  pairs. 

The  next  section  presents  the  final  design,  including  details  about  each  component. 


4.  The  CPR  design 

The  CPR  design  addresses  the  level  of  highest  possible  value,  utility  and  commonality  for 
information  interchange  and  the  development  of  common  services.  Many  details  must  be  left  unspecified 
because  committing  to  a  specific  design  detail  would  prevent  common  description  between  different 
planning  applications. 

In  most  design  efforts  decisions  and  tradeoffs  are  made  and  not  recorded.  Subsequent  design 
efforts  do  not  have  the  advantage  of  reusing  or  being  influenced  by  the  designs  which  were  not  chosen  as 
well  as  the  positive  products  of  a  design.  Each  new  design  must  largely  start  from  scratch.  The  CPR  effort 
has  taken  the  opposite  approach.  Whenever  reasonable  choices  are  encountered,  they  are  recorded. 

The  CPR  design  is  presented  in  several  sections.  The  first  gives  an  overview  of  the  basic  design. 
The  second  raises  a  series  of  issues  which  either  illustrate  reasonable  alternatives  to  the  current  design,  or 
describe  items  which  remain  unresolved.  The  third  section  presents  the  detailed  description  of  the  CPR, 
with  discussion  of  the  components  and  their  design  rationale. 


10 


Core  Plan  Representation  Design 
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Evaluation 

Criterion 


Note:  Any  of  the  objects  above  may  contain  Annotation  or  its  subclasses,  or 
Constraints,  Uncertainty  or  imprecision. 
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4. 1.  Design  Tradeoffs  and  Issues 

Some  of  the  design  issues  were  presented  briefly  in  section  3,  but  are  presented  again  here  for 
completeness. 

1 .  Action  linking.  Action  could  have  a  slot  which  would  be  a  relation  to  another  action. 

This  would  be  very  useful  in  plans  which  have  partially  ordered  sequences  of  actions. 
However,  an  ordering  constraint  is  just  one  type  of  constraint,  so  a  scheme  where  ordering 
constraints  are  represented  like  any  other  constraint  can  be  considered  more  general. 

2.  Action  begin  and  end  times.  These  times  could  be  viewed  as  constraints  since  they  are 
often  not  absolute  times.  There  may  be  justification  not  to  specify  how  Action  will  use 
begin  and  end.  For  example,  some  Actions  are  continuous,  periodic,  or  intermittent  and 
don  t  clearly  have  a  beginning  or  ending.  Possibly  having  a  timeSpecification  attribute 
would  be  an  improvement 

3.  Actions  could  also  have  priority  and  sequence  items  like  ACPT.  These  are  constraints  so 
in  the  minimal  CPR  model  they  are  not  explicit  attributes  of  Action  but  would  be  modeled 
as  instances  of  Constraint. 

4.  Actor  types.  One  alternate  approach  would  be  to  have  different  types  of  Actors.  We 
could  have  Actors  who  cany  out  Actions,  Actors  who  are  influenced  by  Actions,  or 
Actors  who  are  responsible  for  a  Plan.  Currently,  the  CPR  models  the  first  case  only  as 
Actors.  In  the  second  case,  the  entity  may  be  specified  as  a  Constraint  on  an  Action  or  as 
simply  a  Annotation.  In  the  third  case  a  planner  would  be  an  Actor  in  a  workflow  Plan 
which  specifies  the  creation  process  for  a  Plan.  Or  that  entity  might  be  given  as  a  Fact  on 
a  plan  with  author  as  predicate  and  the  entity’s  name  as  the  value  of  the  predicate.  One 

option  would  be  to  specify  Actors  which  are  not  carrying  out  Actions  as  PlanObjects  (see 
PlanObject  below). 

5.  Linking  Actors  and  Actions.  At  the  ontological  level.  Actions  are  carried  out  by  Actors 
and  so  in  an  entity-relationship  diagram  we  definitely  need  a  link  “carried  out  by”.  At  an 
object  oriented  design  level  however  we  have  additional  factors  such  as  software 
modularity  and  maintainability  to  consider.  These  factors  bias  in  favor  of  minimizing  the 
number  of  linkages  between  modules.  We  could 

a)  Have  a  link  (pointer)  from  Action  to  Actor  and  vice  versa 

b)  Have  a  string  “key”  and  a  service  of  Plan  which  retrieves  an  Actor  or  Action 
based  on  that  key.  Actor  would  contain  a  list  of  keys  for  the  Actions  it  performs. 

c)  Have  relationships  between  Actors  and  Actions  given  in  Constraints,  and  have 
the  Constraints  reference  the  string  keys. 

d)  Have  the  Constraints  contain  pointers.  The  CPR  currently  just  has  Actions 
contain  Actors.  If  Actors  needed  be  retrieved  directly,  this  would  require  a 
search  service  on  Plan. 

6.  Assumptions,  Monitors  and  Triggers.  A  capability  to  enter  the  assumptions  on  which 
aspects  of  the  plan  depend  is  necessary.  Also  needed  is  a  hook  to  have  a  specified  action 
take  place  when  that  assumption  changes.  A  minimal  solution  would  be  a  user  interface 
which  enters  assumptions  into  the  plan  as  Annotations  attached  to  the  relevant  part  of  the 
plan.  The  same  interface  would  also  list  all  the  current  assumptions  in  the  plan.  Those 
assumptions  could  have  additional  Annotations  which  specify  what  action  to  take  if  the 
assumption  changes.  A  more  sophisticated  solution  would  be  to  specify  and  supply 
monitor  and  trigger  services  and  allow  the  specification  of  a  workflow  describing  what 
actions  to  take  should  an  assumption  change. 
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7. 


8. 

9. 


10. 


11. 


12. 

13. 

14. 


Action  and  Plan  status.  Representing  status  is  potentially  a  very  complex  problem. 
There  is  a  need  to  represent  the  status  of  individual  Actions,  the  aggregate  status  of  a  Plan 
and  the  status  of  the  context  in  which  the  Plan  exists.  This  is  a  significant  omission  in  the 
current  version  of  the  CPR.  There  needs  to  be  a  coherent  expression  of  all  dynamic 
information  related  to  the  Plan.  This  includes  Plan  and  Action  status  and  information 
about  the  situation.  This  design  will  involve  working  with  situation  description  designs 
like  the  JTF  ATD  situation  server  to  determine  an  appropriate  partitioning. 

Do  Actors  need  to  have  roles?  Is  role  an  attribute  or  a  class?  Is  there  a  need  to  place 
Actors  into  groups?  Is  the  current  hierarchical  structure  of  Actors  and  sub- Actors 
sufficient? 

Plan  attributes  -  subPIan  and  alternatives.  SubPlan  is  an  ontologically  non-minimal 
attribute.  Here  is  another  issue  which  straddles  the  fence  of  philosophical  purity  vs 
implementation  effectiveness.  While  a  really  huge  plan  could  be  encoded  all  as  one  plan, 
there  is  value  to  the  user  in  splitting  it  up  into  manageable  sections.  Microsoft  Project  for 
example  allows  the  user  to  have  multiple  projects  which  are  linked  together.  Each  one  is 
self  contained  yet  can  link  to  the  others.  The  same  concept  is  in  the  CPR. 

PlanObject  superclass.  PlanObject  could  be  seen  as  a  fundamental  object  type  with 
possible  specializations  to  Resource  and  Actor  (performer  of  actions)  and  other  agents. 
This  might  give  an  extendible  framework  for  the  CPR  and  allow  a  relationship  to  several 
existing  workflow  standards  more  easily.  Specifications  ofPlanObjects  could  be  created 
that  perform  certain  roles  in  the  plan,  such  as  performing  an  action  as  an  actor  or  being 
created/modified  or  used  as  a  resource.  However,  this  issue  does  beg  the  question  of  what 
common  state  or  behavior  does  a  PlanObject  embody. 

Constraints  vs.  Facts.  Constraints  are  envisioned  as  allowing  variables  in  the  terms. 

Facts  would  not  allow  variables.  However,  a  completely  specified  Constraint  is  just  a 
fact,  and  there’s  no  reason  why  a  Fact  can’t  specify  incomplete  information.  A  Constraint 
could  be  viewed  as  an  object  with  a  dynamic  function  in  automation.  That  is  to  say 
Constraints  would  be  updated  by  a  constraint  resolver  whereas  Facts  are  intended  to  hold 
information  entered  by  the  user  and  not  modified  by  the  system.  This  is  probably  a  poor 
distinction  however,  since  ideally  the  same  objects  should  be  usable  by  human  or  machine 
in  a  seamless  fashion. 

Location  of  Constraints.  One  possibility  would  be  to  place  all  Constraints  under  Plan 
and  simply  have  them  refer  to  objects  they  constrain  by  a  String  key. 

Resources.  There  may  be  a  reasonable  attribute  to  include  here.  Doesn’t  every  Resource 
have  some  measure  of  how  much  of  it  there  is  and  how  much  of  that  is  being  used  or 
consumed? 

Plan  decompositions  and  Objectives.  SubPlans  and  Actions  are  alternatives  for 
decomposing  plans  and  the  conjunct  of  both  is  the  complete  decomposition  of  a  Plan. 

There  are  several  alternatives  for  how  to  relate  Objectives  in  a  subPIan  with  its  parent 
Plan. 

a)  objectives  in  a  subPIan  must  be  specializations  of  Objectives  in  the  parent 

b)  The  Objectives  in  a  subPIan  must  be  specializations  or  orthogonal  to  the 
Objectives  in  the  parent  Plan. 

c)  The  Objectives  in  a  subPIan  may  override  the  Objectives  of  the  parent  Plan 
much  like  subclassing  in  an  object  oriented  language.  The  Objectives  in  the 
subPIan  are  true  for  the  subPIan  and  the  Objective  in  the  parent  Plan  are  true  for 
the  parent  Plan.  When  Objectives  in  the  subPIan  and  parent  Plan  are  in  conflict. 
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the  resolution  is  undefined.  The  anomalies  are  flagged  for  user  or  system 
resolution  on  a  case  by  case  basis. 

15.  Action  vs.  Plan.  An  Action  in  one  context  could  be  seen  as  a  Plan  in  another.  Both  can 
be  decomposed.  Possibly  they  should  be  the  same  class  or  derived  from  a  common 
superclass. 


4.2.  Detailed  Design  -  Class  Descriptions  (alphabetical  list) 


Action 

name 

subAct ions 

actors 

resources 

planOb ject s 

begin 

end 


String 

List  of  Action 
List  of  Actor 
List  of  Resource 
List  of  PlanObject 
TimePoint 
TimePoint 


Action  contains  a  name,  possibly  a  set  of  decompositions,  the  resources  used  in  carrying  out  the 
Action,  any  PlanObjects  may  be  involved  or  the  object  of  the  Action  and  the  times  at  which  the 
Action  begins  and  ends. 


Actor 

name  :  string 

objectives  :  List  of  String 

subActors  :  List  of  Actor 


An  Actor  is  the  subject  of  an  Action.  The  Actor  may  have  Objectives  which  drive  the  Actions  it 
takes.  Currently  this  is  just  a  String  pointer  to  an  Objective  in  the  Plan.  There  might  be  utility  in 
having  an  Actor  contain  its  own  Objectives  which  are  not  directly  Objectives  of  the  Plan. 
SubActors  is  designed  to  hold  aggregates  of  Actors  like  an  organizational  division  in  which  the 
division  acts  together  but  where  there  is  still  a  need  to  record  information  about  the  individuals 
who  may  act  by  themselves  for  other  Actions. 

Annotation 

name  ;  String 

subAnnotations  :  List  of  Annotation 

An  Annotation  is  designed  to  hold  any  type  of  unstructured  data,  paragraphs  of  text,  pictures, 
video  etc.  It  exists  to  hold  any  information  which  supports  understanding  or  maintenance  of  the 
plan  but  it  not  strictly  part  of  the  plan  itself.  Note:  This  was  previously  called  PlanDataElement. 

Assumption 

data  :  (undefined) 

triggerCondit ion  :  (undefined) 

triggerAction  :  (undefined) 

An  Assumption  is  intended  to  identify  any  information  on  which  the  plan  information  depends. 
TriggerCondition  describe  what  kind  of  change  in  the  data  will  activate  the  triggerAction. 
TriggerAction  will  specify  the  action  to  be  taken  if  the  data  changes  according  to  the 
triggeiCondition.  This  object  is  a  weak  link  between  the  CPR  and  dynamic  entities  which  provide 
data  on  the  current  situation.  More  work  needs  to  be  done  to  determine  what  the  best  linkages  are 
and  how  to  integrate  situation  status  and  plan  status. 

Constraint 

name  : 

terms  : 

Xeve lOf Hardness  : 

SubConstraints  : 


String  (a  predicate  name) 

List  of  String  (terms  for  the  predicate) 
Integer 

List  of  Constraint 
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This  object  holds  any  formal  restrictions  on  an  entity  in  the  plan.  Name  and  terms  hold  the 
expression  of  the  Constraint,  for  example  before(actionl  .begin,action2.begin)  or 
greaterThan(numberOfTanks,100).  LevelOfHardness  describes  how  strict  the  Constraint  is.  Is  the 
Constraint  an  absolute,  or  is  it  simply  guidance  which  may  be  overridden  if  necessary?  This  may 
be  too  specific.  Also,  specifying  the  level  as  a  number  is  probably  too  weak.  What  would  most 
likely  be  needed  would  be  a  partial  order  on  an  ontology  of  Constraints  indicating  which 
Constraint  would  take  precedence  over  another. 

EvaluationCriterion 

This  object  currently  has  no  attributes.  While  there  is  a  general  need  for  Objectives  to  have 
evaluation  criteria,  it  is  believed  than  any  further  specification  is  too  specific  for  the  CPR. 
Specializations  of  the  CPR  however,  will  subclass  useful  specific  versions  of  EvaluationCriterion. 


Fact 

name  :  String 

terms  :  List  of  String 

A  Fact  is  one  very  general  specification  of  a  structured  unspecified  data  element.  It  is  supposed  to 
handle  information  like  hasCar(john),  likes(Mary,  Bob).  It  is  really  only  useful  as  a  way  to 
exchange  information  between  planners  when  there  is  not  a  direct  corresponding  slot  for  structured 
information. 

Frame 

slotList  :  a  List  of  (Attribute,  Value)  pairs 

Like  Fact,  this  object  is  a  very  general  specification  of  a  structured  unspecific  data  element  It  is 
really  only  useful  as  a  way  to  exchange  information  between  planners  when  there  is  not  a  direct 
corresponding  set  of  slots  for  structured  information. 

Imprecision 

type  ;  string 

measure  :  (undefined) 

source  :  (undefined) 

The  Imprecision  object  holds  a  measure  of  the  imprecision  or  fuzziness  [Zadeh,  1978]  associated 
with  a  piece  of  information.  There  are  different  possibilities  for  an  imprecision  measurement  We 
might  have  simply  a  linguistic  variable,  or  a  linguistic  variable  with  an  associated  fuzzy 
membership  function.  Drawing  on  endorsement  research  [Cohen,  1985],  we  might  add  an  attribute 
for  the  source  of  the  imprecision.  There  might  be  imprecision  due  to  the  measurement  equipment 
or  perturbations  in  the  transmission  of  information  for  example. 


Objective 

type  :  String 

value  :  string 

actions  :  List  of  String 

evaluationCriteria  :  List  of  EvaluationCriterion 

subObjectives  :  List  of  Objective 

Objectives  may  also  contain  subordinate  Objectives.  The  current  idea  is  to  place  Objectives  under 
Plan  and  have  them  point  to  the  Actions  which  are  designed  to  satisfy  them.  The  pointer  is 
currently  just  a  String  which  may  not  be  the  best  design. 


Plan 

name 

subPlans 

object ives 

actions 

alternatives 

evaluation 

issues 


String 

List  of  Plans 

List  of  Objective 

List  of  Actions 

List  of  Strings 

Annotation 

List  of  Annotations 


15 


Plan  is  the  aggregate  object  of  this  representation.  SubPlans  are  Plans  into  which  this  top  level 
Plan  may  be  elaborated.  Actions  specify  in  detail  how  the  Plan  is  accomplished.  Alternatives  is  a 
List  of  Strings  which  refer  to  Plans  which  accomplish  similar  things.  This  is  probably  not  the  best 
way  to  represent  this.  Alternatives  occur  in  several  areas  of  the  Plan.  There  may  be  several  related 
Plans  which  all  belong  at  an  equal  level  in  a  hierarchy.  Possibly  some  higher  level  object  is 
required.  Evaluation  is  an  Annotation  describing  the  merits  of  this  Plan  relative  to  other  Plans. 
This  is  different  from  an  EvaluationCriterion  which  describes  how  well  a  Plan  is  meeting  a  specific 
Objective.  Issues  is  a  List  of  Annotations  which  describes  areas  of  the  Plan  which  a  planner 
(human  or  machine)  needs  to  record  as  being  incomplete  or  in  question. 

PlanObject 

name  :  String 

PlanObject  is  intended  to  contain  information  about  an  entity  which  is  referred  to  in  the  description 
of  an  Action  which  is  not  an  Actor  or  a  Resource.  It  is  helpful  in  creating  a  correspondence  with 
the  design  of  PEF. 

Resource 

name  :  String 

There  are  all  sorts  of  useful  specializations  of  Resource.  They  are  currently  believed  to  be  too 
specific  for  inclusion  in  the  CPR. 

Uncertainty 

type  :  String 

measure  :  (undefined) 

source  :  (undefined) 

The  Uncertainty  object  holds  a  measure  of  the  uncertainty  associated  with  a  piece  of  information. 
There  are  many  possibilities  for  an  Uncertainty  measurement.  A  Bayesian  [Feller,  1957]  scheme 
might  have  a  single  real  number,  a  Dempster-Shafer  [Shafer,  1976]  scheme  two  numbers,  a  simple 
certainty  factor  method  might  have  a  single  integer,  an  endorsement  scheme  [Cohen,  1985]  might 
have  an  enumerated  type.  Drawing  on  endorsement  research,  we  might  add  an  attribute  for  the 
source  of  the  uncertainty.  There  might  be  uncertainty  due  to  unreliability  of  the  source,  or  of 
predication  of  a  future  event  for  example. 


5.  Conclusion 

This  proposal  has  provided  references  to  planning  research  and  suggested  the  need  for  a  common, 
unified  representation  of  a  plan.  Basic  plan  concepts  were  offered,  concepts  were  assembled  into  a  design 
framework  and  then  refined.  Design  issues  regarding  this  proposal  were  raised,  many  with  suggested 
resolutions. 

Comments,  concerns,  or  deficiencies  should  be  submitted  to  Adam  Pease  at 
apease@teknowledge.com.  Input  will  be  valuable  at  any  time,  but  to  influence  the  ongoing  design  effort, 
comments  are  best  submitted  by  November  30th,  1996. 
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Abbreviations 


ACPT 

Air  Campaign  Planning  Tool 

ARPA 

Advanced  Research  Projects  Agency 

ARPI 

ARP  A/Rome  Lab  Planning  Initiative 

CPR 

Core  Plan  Representation 

DoD 

Department  of  Defense 

I-N-OVA 

Issues  -  Nodes  -  Orderings/Variables/Auxiliary 

JFACC 

Joint  Forces  Air  Component  Commander 

JTF  ATD 

Joint  Task  Force  Advanced  Technology  Demonstration 

KRSL 

Knowledge  Representation  Source  Language 

OMWG 

Object  Model  Working  Group 

O-Plan 

Open  Planning  architecture 

POCG 

Plan  Ontology  Construction  Group 
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